At 4:50 AM -0700 6/12/98, Stupor Genius wrote:
>One comment...when you ran the tests in succession, could the cache be
>responsible for the timing groupings in the same test? Should a
>little program be run in between to "flush" the cache full of garbage
>so each real run will miss? Seem to recall a little program, in CUJ,
>I think, that set up a big array and then iterated over it to trash
>the cache.
Obviously I'm commenting at second hand, and perhaps this problem is
handled properly, but:
Many CPU's have independent data and instruction caches. Setting up a big
array and moving through it will flush the data cache, but most benchmark
anomalies are likely to be due to the instruction cache, aren't they?
Also, if you have a process (program) stop and then restart is the OS smart
enough to reconnect the VM state in such a way that the cache isn't flushed
anyway? Can it even preserve cache coherence through a fork (when the VM
state is mostly preserved)? I doubt it.
That said if you are testing multiple SQL statements within a single
connection (so the backend doesn't fork a new process) then I could see
some anomalies. Otherwise I doubt it.
Anyone know better?
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
